An IMS network is an architectural framework for providing Internet Protocol (IP) multimedia services (e.g., Voice-over-IP telephony) to subscribers. The IMS network generally includes three different layers: the application layer, the session layer, and the transport layer. The application layer includes application servers that provide various types of call support services to the subscribers. The session layer (also known as the IMS core network) manages user authentication, user equipment (UE) registration, and routing of signaling and other call-related packets between the application layer and the transport layer. The transport layer includes gateways that interface with various external networks (e.g., PSTN, Internet) and performs call control protocol conversion and transformation.
Various types of Call Session Control Function (CSCF) nodes (e.g., Proxy CSCF, Interrogating CSCF, Serving CSCF) are included as part of the session layer. The Serving CSCF (S-CSCF nodes) are generally configured as the central nodes in the session layer. The S-CSCF nodes perform several aspects of session control including, for example, handling UE registrations, determining to which application server(s) to forward messages, and enforcing policies of the IMS network operator. Any given deployment of an IMS network can include multiple S-CSCF nodes. The particular S-CSCF node that registers the UE of a subscriber is assigned dynamically at the time of UE registration. In addition, all subsequent messages from the UE are routed to the same S-CSCF node using standard IMS procedures.
FIG. 1 is a block diagram illustrating a typical IMS network configuration 100 for providing IP multimedia services to subscribers. The network configuration 100 includes user equipment 102a-b (e.g., mobile phones), a plurality of S-CSCF nodes 104a-c, a plurality of IMS Service Control (ISC) links 106a-b, a multimedia telephony (MMTel) application server pool 108 containing a plurality of MMTel application servers 110a-b, and an IP Short Message Gateway (IP-SM-GW) application server pool 112 including a plurality of IP-SM-GW application servers 114a-b. 
In the IMS domain, the actual multimedia service is provided by the application servers in the application layer. Some examples of application servers include MMTeI servers (e.g., MMTel servers 110a-b), Presence servers, IP-SM-GW servers (e.g., TP-SM-GW servers 114a-b), and IP Multimedia Service Switching Function (IM-SSF) servers. Nodes such as the MMTel servers 110a-b and Presence servers provide multimedia services to the IMS subscribers and generally do not interact with a Global System for Multimedia Communications (GSM)/3rd Generation Partnership Project (3GPP) network using a Mobile Application Part (MAP)/CAMEL Application Part (CAP) interface.
However, nodes such as the IP-SM-GW servers 114a-b and the IM-SSF server act like SIP application servers towards the session layer. These nodes support SIP messaging toward the IMS core network and also support MAP/CAP messaging towards GSM/3GPP networks. As a result, these nodes must be identifiable to each of the respective IMS and GSM/3GPP networks. To accomplish the identification, the nodes 114a-b are identified by a SIP Uniform Resource Identifier (URI), e.g., an IP Address or Fully Qualified Domain Name (FQDN) in the IMS domain, and by an assigned E.164 number in the GSM/3GPP domain. In other words, the assigned SIP URI is used by the IMS core network to communicate on the SIP interface and the assigned E.164 address is used by the GSM/3GPP network to communicate over the MAP/CAP interface.
Each UE (e.g., UE 102a-b) in an IMS domain is identified by a SIP URI of type sip:<username>@<domain> (e.g., bob@sonusnet.com) and/or a Tel URL (e.g., tel:+91-80-41902629). When the UE 102a-b of a subscriber registers with the IMS network, the particular S-CSCF node 104a-c that will communicate with the UE 102a-b is dynamically assigned. The assigned S-CSCF node (e.g., node 104a), in turn, selects an application server (e.g., MMTel server 110a, IP-SM-GW server 114a, IM-SSF AS) based on initial filter criteria (iFC) associated with the subscriber/UE. The iFC for a subscriber/UE is configured by the network operator at the Home Subscriber Server (HSS) in the session layer of the IMS network. The iFC contains the address of the application server to be contacted, and the application server address can be specified as an IP address or FQDN in the iFC. For example:                If the application server (e.g., IP-SM-GW server 114a) is identified by an IP address—the S-CSCF node (e.g., node 104a) selects the application server 114a using the IP address. In this example, the UE-to-application server mapping is static.        If the application server is (e.g., IP-SM-GW server 114a) identified by a FQDN, the S-CSCF node (e.g., node 104a) resolves the FQDN using Domain Name System (DNS) procedures which return one or more IP addresses. The S-CSCF node 104a selects one of the returned IP addresses to forward SIP requests at the time of third-party UE registration. The S-CSCF node 104a stores the association between the UE (e.g., UE 102a) and the IP address, and forwards all subsequent requests received from the UE 102a to the IP address associated with the application server 114a. In this example, the UE-AS mapping is dynamic and is selected by the S-CSCF node.        
In a GSM/3GPP domain, the UE 102a is identified by a Mobile Subscriber Integrated Services Digital Network Number (MSISDN) or an International Mobile Subscriber Identity (IMSI). At least one of the MSISDN and IMSI is contained in MAP/CAP messages associated with a given subscriber/UE. When the UE 102a registers, the subscriber's IMSI is passed to the application server 114a via the ISC link 106b as a part of a third-party registration message (e.g., the message body of an SIP REGISTER message). The application server 114a can also retrieve the MSIDN for the subscriber via the Sh interface.
When a GSM/3GPP network sends a MAP/CAP message intended for a subscriber/UE (e.g., UE 102a), the MAP/CAP message is addressed to the E.164 address of the application server 114a.                 Where the application server is an IP-SM-GW server, the E.164 address is stored in the HLR/HSS for every subscriber. When a subscriber registers with the IMS network, the IP-SM-GW application server registers with the HSS/HLR using the same E.164 number. When the Short Message Service Center (SMSC) does a HLR lookup to deliver a Short Message Service (SMS) message to the subscriber, the E.164 address of the IP-SM-GW application server is retuned to the SMSC.        Where the application server is an IM-SSF server, the GSM Service Control Function (gsmSCF) can invoke operations to establish a new TCAP dialog. For example, CAP-Initiate-Call-Attempt is one such operation which can be used to create a completely new call. The E.164 address is stored in the Service Control Point (SCP) for every subscriber. When the SCP invokes the CAP-Initiate-Call-Attempt operation, the CAP message is addressed to the E.164 address of the IM-SSF server.        
FIG. 2 is a block diagram illustrating a typical IMS network configuration 200 for providing IP multimedia services to subscribers, where the application servers (e.g., IP-SM-GW 114a-b) each have an individual E.164 address and an individual IP address. The network configuration 200 includes a Home Location Register (HLR) 202, a Short Message Service Center (SMSC) 202, a plurality of UE 102a-b, a plurality of S-CSCF nodes 104a-c, and an IP-SM-GW application server pool 112 with a plurality of IP-SM-GW nodes 114a-b. It should be understood that the network configuration can also include IM-SSF application servers that are connected to the HLR 202/SMSC 204 and the plurality of S-SCSF nodes 104a-c. Each of the IP-SM-GW nodes 114a-b are assigned an individual E.164 address 206a-b and an individual IP address 208a-b. The iFC of the UE 102a-b can be configured to refer to the IP address 208a-b of an individual IP-SM-GW 114a-b, resulting in a fixed UE to IP-SM-GW application server mapping. In addition, as long as the corresponding E.164 addresses 206a-b are configured in HLR 202, any MAP/CAP messages intended for a given UE 102a-b can be directed toward the same IP-SM-GW application server 114a-b. 
However, the network configuration 200 requires that a distinct E.164 address (e.g., addresses 206a-b) is allocated to each of the IP-SM-GW application servers 114a-b. The operator of the network has to intelligently configure each of the subscriber records to distribute registration requests and service appropriately across the application servers, and the operator must configure both the E.164 address 206a-b in HLR 202 and the IP address 208a-b in the iFC at the Home Subscriber Server (HSS). The operator also has to ensure that the IP address 206a-b in the iFC and the E.164 address 208a-b in HLR 202 refer to the same application server 114a-b for a given UE 102a-b. In addition, the operator must allocate a new E.164 address whenever a new application server instance is added to the network and intelligently provision the same against a subscriber. Thus, the operator incurs a provisioning overhead.
FIG. 3 is a block diagram illustrating a typical IMS network configuration 300 for providing IP multimedia services to subscribers, where the application servers 114a-b share a single FQDN 302 and the application servers 114a-b share a single E.164 address 304. The network configuration 300 includes a Home Location Register 202, a Short Message Service Center 204, a plurality of UE 102a-b, a plurality of S-CSCF nodes 104a-c, and an IP-SM-GW application server pool 112 with a plurality of IP-SM-GW nodes 114a-b. It should be understood that the network configuration can also include IM-SSF application servers that are connected to a Service Control Point (SCP) and the plurality of S-SCSF nodes 104a-c. The plurality of IP-SM-GW nodes 114a-b are identified to the plurality of S-CSCF nodes 104a-c by a single FQDN 302. The iFC of the UE 102a-b refers to the FQDN 302 as the address of the application server 114a-b to which the UE 102a-b connects. The S-CSCF node 114a-c selects one of the application servers 114a-b through DNS resolution. The subscriber and UE 102a-b can get allocated to any of the application servers 114a-b via dynamic assignment at the time of registration. To eliminate the provisioning overhead described in relation to FIG. 2, the operator similarly configures the application servers 114a-b to share a single E.164 number 304.
However, when a MAP/CAP message is received from the circuit-switched domain, the IMS network needs to identify the particular application server to direct the message based on where the subscriber and UE is currently registered. As shown in FIG. 3, the network cannot use the E.164 number 304 to identify a distinct application server because all of the application servers 114a-b use the same E.164 number 304. The MAP/CAP messages are meant for a given UE 102a-b and subscriber, and the messages contain the MSISDN and IMSI of the UE 102a-b. Therefore, what is needed is a technique to identify a particular application server in a plurality of application servers, where the plurality of application servers are associated with a shared E.164 identifier.